bpo-46998: Allow subclassing Any at runtime #31841
Conversation
|
This PR also permits The error in |
Misc/NEWS.d/next/Library/2022-03-13-08-52-58.bpo-46998.cHh-9O.rst
Outdated
Show resolved
Hide resolved
| with self.assertRaisesRegex(TypeError, "Invalid first argument to "): | ||
| f.register(typing.List[float] | bytes, lambda arg: "typing.Union[typing.GenericAlias]") | ||
| with self.assertRaisesRegex(TypeError, "Invalid first argument to "): | ||
| f.register(typing.Any, lambda arg: "typing.Any") |
There was a problem hiding this comment.
This might be worth forbidding explicitly because the behavior could be quite unintuitive. Happy to leave that decision to the functools maintainer though.
There was a problem hiding this comment.
@ambv, do you have any thoughts on the bits of this PR that touch singledispatch?
| @_SpecialForm | ||
| def Any(self, parameters): | ||
| class _AnyMeta(type): | ||
| def __instancecheck__(self, obj): |
There was a problem hiding this comment.
Should we even have this? isinstance(X, Any) is now a meaningful operation.
There was a problem hiding this comment.
I'm fine with removing it (as this PR currently does for issubclass). Doing so would also allow us to get rid of the metaclass, which will help remove restrictions on what classes can inherit from Any.
My reasoning for keeping it is that isinstance is very commonly used, potentially by typing / Python novices, and isinstance(..., Any) doesn't correspond well to the notion of Any at type check time. Sophisticated users have workarounds available to them for the equivalent isinstance check.
|
|
||
| @_SpecialForm | ||
| def Any(self, parameters): | ||
| class _AnyMeta(type): |
There was a problem hiding this comment.
The metaclass is unfortunate because it restricts what classes can double-inherit from Any (due to metaclass conflicts). Seems unavoidable though.
There was a problem hiding this comment.
Not entirely unavoidable, if we were willing to give up on instancecheck (and repr), I'd say we could just remove the metaclass entirely
|
Planning to merge in a few days unless there's more discussion. |
JelleZijlstra
left a comment
There was a problem hiding this comment.
Looking at it again, I realize we should document this. Probably fine to just add a note like .. versionchanged: 3.11: Any can now be used as a base class.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase And if you don't make the requested changes, you will be poked with soft cushions! |
|
Thanks for making the requested changes! @JelleZijlstra: please review the changes made to this pull request. |
Doc/library/typing.rst
Outdated
| * :data:`Any` is compatible with every type. | ||
|
|
||
| .. versionchanged:: 3.11 | ||
| :data:`Any` can now be used as a base class |
There was a problem hiding this comment.
Can you add some explanation about the use cases?
This doesn’t say why someone could want that, nor does the ticket, one has to hunt for the last message in the mailing list thread!
There was a problem hiding this comment.
I added a sentence here. Let me know if I should make it longer; I tried to keep it short because this is a lot more niche than other things covered in typing.rst
There was a problem hiding this comment.
I think adding one short example might be nice
There was a problem hiding this comment.
Not sure about this. On the one hand an example would be useful; on the other hand it risks putting too much emphasis on a pretty obscure use case.
There was a problem hiding this comment.
Let's omit the example then (devguide says "err on the side of being succinct" for docs). I'm hoping to do some work on typing docs sometime soon, which might be a better home for such details.
https://bugs.python.org/issue46998